home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_8.lha / rfc1723 < prev    next >
Text File  |  1995-07-26  |  19KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          G. Malkin
  8. Request for Comments: 1723                                Xylogics, Inc.
  9. Obsoletes: 1388                                            November 1994
  10. Updates: 1058
  11. Category: Standards Track
  12.  
  13.  
  14.                              RIP Version 2
  15.                     Carrying Additional Information
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    This document specifies an extension of the Routing Information
  28.    Protocol (RIP), as defined in [1,2], to expand the amount of useful
  29.    information carried in RIP messages and to add a measure of security.
  30.    This memo obsoletes RFC 1388, which specifies an update to the
  31.    "Routing Information Protocol" STD 34, RFC 1058.
  32.  
  33.    The RIP-2 protocol analysis is documented in RFC 1721 [4].
  34.  
  35.    The RIP-2 applicability statement is document in RFC 1722 [5].
  36.  
  37.    The RIP-2 MIB description is defined in RFC 1724 [3].  This memo
  38.    obsoletes RFC 1389.
  39.  
  40. Acknowledgements
  41.  
  42.    I would like to thank the IETF ripv2 Working Group for their help in
  43.    improving the RIP-2 protocol.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Malkin                                                          [Page 1]
  59.  
  60. RFC 1723                     RIP Version 2                 November 1994
  61.  
  62.  
  63. Table of Contents
  64.  
  65.    1.  Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2
  66.    2.  Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2
  67.    3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3
  68.    3.1   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 4
  69.    3.2   Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  70.    3.3   Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5
  71.    3.4   Next Hop  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  72.    3.5   Multicasting  . . . . . . . . . . . . . . . . . . . . . . . . 5
  73.    3.6   Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  74.    4.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6
  75.    4.1   Compatibility Switch  . . . . . . . . . . . . . . . . . . . . 6
  76.    4.2   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 6
  77.    4.3   Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7
  78.    4.4   Addressless Links . . . . . . . . . . . . . . . . . . . . . . 7
  79.    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
  80.    Appendix A  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
  81.    References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
  82.    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9
  83.  
  84. 1. Justification
  85.  
  86.    With the advent of OSPF and IS-IS, there are those who believe that
  87.    RIP is obsolete.  While it is true that the newer IGP routing
  88.    protocols are far superior to RIP, RIP does have some advantages.
  89.    Primarily, in a small network, RIP has very little overhead in terms
  90.    of bandwidth used and configuration and management time.  RIP is also
  91.    very easy to implement, especially in relation to the newer IGPs.
  92.  
  93.    Additionally, there are many, many more RIP implementations in the
  94.    field than OSPF and IS-IS combined.  It is likely to remain that way
  95.    for some years yet.
  96.  
  97.    Given that RIP will be useful in many environments for some period of
  98.    time, it is reasonable to increase RIP's usefulness.  This is
  99.    especially true since the gain is far greater than the expense of the
  100.    change.
  101.  
  102. 2. Current RIP
  103.  
  104.    The current RIP message contains the minimal amount of information
  105.    necessary for routers to route messages through a network.  It also
  106.    contains a large amount of unused space, owing to its origins.
  107.  
  108.    The current RIP protocol does not consider autonomous systems and
  109.    IGP/EGP interactions, subnetting, and authentication since
  110.    implementations of these postdate RIP.  The lack of subnet masks is a
  111.  
  112.  
  113.  
  114. Malkin                                                          [Page 2]
  115.  
  116. RFC 1723                     RIP Version 2                 November 1994
  117.  
  118.  
  119.    particularly serious problem for routers since they need a subnet
  120.    mask to know how to determine a route.  If a RIP route is a network
  121.    route (all non-network bits 0), the subnet mask equals the network
  122.    mask.  However, if some of the non-network bits are set, the router
  123.    cannot determine the subnet mask.  Worse still, the router cannot
  124.    determine if the RIP route is a subnet route or a host route.
  125.    Currently, some routers simply choose the subnet mask of the
  126.    interface over which the route was learned and determine the route
  127.    type from that.
  128.  
  129. 3. Protocol Extensions
  130.  
  131.    This document does not change the RIP protocol per se.  Rather, it
  132.    provides extensions to the message format which allows routers to
  133.    share important additional information.
  134.  
  135.    The first four octets of a RIP message contain the RIP header.  The
  136.    remainder of the message is composed of 1 - 25 route entries (20
  137.    octets each).  The new RIP message format is:
  138.  
  139.     0                   1                   2                   3 3
  140.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  141.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.    | Command (1)   | Version (1)   |           unused              |
  143.    +---------------+---------------+-------------------------------+
  144.    | Address Family Identifier (2) |        Route Tag (2)          |
  145.    +-------------------------------+-------------------------------+
  146.    |                         IP Address (4)                        |
  147.    +---------------------------------------------------------------+
  148.    |                         Subnet Mask (4)                       |
  149.    +---------------------------------------------------------------+
  150.    |                         Next Hop (4)                          |
  151.    +---------------------------------------------------------------+
  152.    |                         Metric (4)                            |
  153.    +---------------------------------------------------------------+
  154.  
  155.    The Command, Address Family Identifier (AFI), IP Address, and Metric
  156.    all have the meanings defined in RFC 1058.  The Version field will
  157.    specify version number 2 for RIP messages which use authentication or
  158.    carry information in any of the newly defined fields.  The contents
  159.    of the unused field (two octets) shall be ignored.
  160.  
  161.    All fields are coded in IP network byte order (big-endian).
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Malkin                                                          [Page 3]
  171.  
  172. RFC 1723                     RIP Version 2                 November 1994
  173.  
  174.  
  175. 3.1 Authentication
  176.  
  177.    Since authentication is a per message function, and since there is
  178.    only one 2-octet field available in the message header, and since any
  179.    reasonable authentication scheme will require more than two octets,
  180.    the authentication scheme for RIP version 2 will use the space of an
  181.    entire RIP entry.  If the Address Family Identifier of the first (and
  182.    only the first) entry in the message is 0xFFFF, then the remainder of
  183.    the entry contains the authentication.  This means that there can be,
  184.    at most, 24 RIP entries in the remainder of the message.  If
  185.    authentication is not in use, then no entries in the message should
  186.    have an Address Family Identifier of 0xFFFF.  A RIP message which
  187.    contains an authentication entry would begin with the following
  188.    format:
  189.  
  190.     0                   1                   2                   3 3
  191.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  192.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  193.    | Command (1)   | Version (1)   |            unused             |
  194.    +---------------+---------------+-------------------------------+
  195.    |             0xFFFF            |    Authentication Type (2)    |
  196.    +-------------------------------+-------------------------------+
  197.    ~                       Authentication (16)                     ~
  198.    +---------------------------------------------------------------+
  199.  
  200.    Currently, the only Authentication Type is simple password and it is
  201.    type 2.  The remaining 16 octets contain the plain text password.  If
  202.    the password is under 16 octets, it must be left-justified and padded
  203.    to the right with nulls (0x00).
  204.  
  205. 3.2 Route Tag
  206.  
  207.    The Route Tag (RT) field is an attribute assigned to a route which
  208.    must be preserved and readvertised with a route.  The intended use of
  209.    the Route Tag is to provide a method of separating "internal" RIP
  210.    routes (routes for networks within the RIP routing domain) from
  211.    "external" RIP routes, which may have been imported from an EGP or
  212.    another IGP.
  213.  
  214.    Routers supporting protocols other than RIP should be configurable to
  215.    allow the Route Tag to be configured for routes imported from
  216.    different sources.  For example, routes imported from EGP or BGP
  217.    should be able to have their Route Tag either set to an arbitrary
  218.    value, or at least to the number of the Autonomous System from which
  219.    the routes were learned.
  220.  
  221.    Other uses of the Route Tag are valid, as long as all routers in the
  222.    RIP domain use it consistently.  This allows for the possibility of a
  223.  
  224.  
  225.  
  226. Malkin                                                          [Page 4]
  227.  
  228. RFC 1723                     RIP Version 2                 November 1994
  229.  
  230.  
  231.    BGP-RIP protocol interactions document, which would describe methods
  232.    for synchronizing routing in a transit network.
  233.  
  234. 3.3 Subnet mask
  235.  
  236.    The Subnet Mask field contains the subnet mask which is applied to
  237.    the IP address to yield the non-host portion of the address.  If this
  238.    field is zero, then no subnet mask has been included for this entry.
  239.  
  240.    On an interface where a RIP-1 router may hear and operate on the
  241.    information in a RIP-2 routing entry the following rules apply:
  242.  
  243.    1) information internal to one network must never be advertised into
  244.       another network,
  245.  
  246.    2) information about a more specific subnet may not be advertised
  247.       where RIP-1 routers would consider it a host route, and
  248.  
  249.    3) supernet routes (routes with a netmask less specific than the
  250.       "natural" network mask) must not be advertised where they could be
  251.       misinterpreted by RIP-1 routers.
  252.  
  253. 3.4 Next Hop
  254.  
  255.    The immediate next hop IP address to which packets to the destination
  256.    specified by this route entry should be forwarded.  Specifying a
  257.    value of 0.0.0.0 in this field indicates that routing should be via
  258.    the originator of the RIP advertisement.  An address specified as a
  259.    next hop must, per force, be directly reachable on the logical subnet
  260.    over which the advertisement is made.
  261.  
  262.    The purpose of the Next Hop field is to eliminate packets being
  263.    routed through extra hops in the system.  It is particularly useful
  264.    when RIP is not being run on all of the routers on a network.  A
  265.    simple example is given in Appendix A.  Note that Next Hop is an
  266.    "advisory" field.  That is, if the provided information is ignored, a
  267.    possibly sub-optimal, but absolutely valid, route may be taken.  If
  268.    the received Next Hop is not directly reachable, it should be treated
  269.    as 0.0.0.0.
  270.  
  271. 3.5 Multicasting
  272.  
  273.    In order to reduce unnecessary load on those hosts which are not
  274.    listening to RIP-2 messages, an IP multicast address will be used for
  275.    periodic broadcasts.  The IP multicast address is 224.0.0.9.  Note
  276.    that IGMP is not needed since these are inter-router messages which
  277.    are not forwarded.
  278.  
  279.  
  280.  
  281.  
  282. Malkin                                                          [Page 5]
  283.  
  284. RFC 1723                     RIP Version 2                 November 1994
  285.  
  286.  
  287.    In order to maintain backwards compatibility, the use of the
  288.    multicast address will be configurable, as described in section 4.1.
  289.    If multicasting is used, it should be used on all interfaces which
  290.    support it.
  291.  
  292. 3.6 Queries
  293.  
  294.    If a RIP-2 router receives a RIP-1 Request, it should respond with a
  295.    RIP-1 Response.  If the router is configured to send only RIP-2
  296.    messages, it should not respond to a RIP-1 Request.
  297.  
  298. 4. Compatibility
  299.  
  300.    RFC 1058 showed considerable forethought in its specification of the
  301.    handling of version numbers.  It specifies that RIP messages of
  302.    version 0 are to be discarded, that RIP messages of version 1 are to
  303.    be discarded if any Must Be Zero (MBZ) field is non-zero, and that
  304.    RIP messages of any version greater than 1 should not be discarded
  305.    simply because an MBZ field contains a value other than zero.  This
  306.    means that the new version of RIP is totally backwards compatible
  307.    with existing RIP implementations which adhere to this part of the
  308.    specification.
  309.  
  310. 4.1 Compatibility Switch
  311.  
  312.    A compatibility switch is necessary for two reasons.  First, there
  313.    are implementations of RIP-1 in the field which do not follow RFC
  314.    1058 as described above.  Second, the use of multicasting would
  315.    prevent RIP-1 systems from receiving RIP-2 updates (which may be a
  316.    desired feature in some cases).  This switch should be configurable
  317.    on a per-interface basis.
  318.  
  319.    The switch has four settings: RIP-1, in which only RIP-1 messages are
  320.    sent; RIP-1 compatibility, in which RIP-2 messages are broadcast;
  321.    RIP-2, in which RIP-2 messages are multicast; and "none", which
  322.    disables the sending of RIP messages.  The recommended default for
  323.    this switch is RIP-1 compatibility.
  324.  
  325.    For completeness, routers should also implement a receive control
  326.    switch which would determine whether to accept, RIP-1 only, RIP-2
  327.    only, both, or none.  It should also be configurable on a per-
  328.    interface basis.
  329.  
  330. 4.2 Authentication
  331.  
  332.    The following algorithm should be used to authenticate a RIP message.
  333.    If the router is not configured to authenticate RIP-2 messages, then
  334.    RIP-1 and unauthenticated RIP-2 messages will be accepted;
  335.  
  336.  
  337.  
  338. Malkin                                                          [Page 6]
  339.  
  340. RFC 1723                     RIP Version 2                 November 1994
  341.  
  342.  
  343.    authenticated RIP-2 messages shall be discarded.  If the router is
  344.    configured to authenticate RIP-2 messages, then RIP-1 messages and
  345.    RIP-2 messages which pass authentication testing shall be accepted;
  346.    unauthenticated and failed authentication RIP-2 messages shall be
  347.    discarded.  For maximum security, RIP-1 messages should be ignored
  348.    when authentication is in use (see section 4.1).
  349.  
  350.    Since an authentication entry is marked with an Address Family
  351.    Identifier of 0xFFFF, a RIP-1 system would ignore this entry since it
  352.    would belong to an address family other than IP.  It should be noted,
  353.    therefore, that use of authentication will not prevent RIP-1 systems
  354.    from seeing RIP-2 messages.  If desired, this may be done using
  355.    multicasting, as described in sections 3.5 and 4.1.
  356.  
  357. 4.3 Larger Infinity
  358.  
  359.    While on the subject of compatibility, there is one item which people
  360.    have requested: increasing infinity.  The primary reason that this
  361.    cannot be done is that it would violate backwards compatibility.  A
  362.    larger infinity would obviously confuse older versions of rip.  At
  363.    best, they would ignore the route as they would ignore a metric of
  364.    16.  There was also a proposal to make the Metric a single octet and
  365.    reuse the high three octets, but this would break any implementations
  366.    which treat the metric as a 4-octet entity.
  367.  
  368. 4.4 Addressless Links
  369.  
  370.    As in RIP-1, addressless links will not be supported by RIP-2.
  371.  
  372. 5. Security Considerations
  373.  
  374.    The basic RIP protocol is not a secure protocol.  To bring RIP-2 in
  375.    line with more modern routing protocols, an extensible authentication
  376.    mechanism has been incorporated into the protocol enhancements.  This
  377.    mechanism is described in sections 3.1 and 4.2.
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Malkin                                                          [Page 7]
  395.  
  396. RFC 1723                     RIP Version 2                 November 1994
  397.  
  398.  
  399. Appendix A
  400.  
  401.    This is a simple example of the use of the next hop field in a rip
  402.    entry.
  403.  
  404.       -----   -----   -----           -----   -----   -----
  405.       |IR1|   |IR2|   |IR3|           |XR1|   |XR2|   |XR3|
  406.       --+--   --+--   --+--           --+--   --+--   --+--
  407.         |       |       |               |       |       |
  408.       --+-------+-------+---------------+-------+-------+--
  409.         <-------------RIP-2------------->
  410.  
  411.    Assume that IR1, IR2, and IR3 are all "internal" routers which are
  412.    under one administration (e.g. a campus) which has elected to use
  413.    RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under
  414.    separate administration (e.g. a regional network, of which the campus
  415.    is a member) and are using some other routing protocol (e.g. OSPF).
  416.    XR1, XR2, and XR3 exchange routing information among themselves such
  417.    that they know that the best routes to networks N1 and N2 are via
  418.    XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By
  419.    setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for
  420.    N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for
  421.    routing to occur without additional hops through XR1. Without the
  422.    Next Hop (for example, if RIP-1 were used) it would be necessary for
  423.    XR2 and XR3 to also participate in the RIP-2 protocol to eliminate
  424.    extra hops.
  425.  
  426. References
  427.  
  428.    [1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058,
  429.        Rutgers University, June 1988.
  430.  
  431.    [2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
  432.        RFC 1388, Xylogics, Inc., January 1993.
  433.  
  434.    [3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
  435.        1724, Xylogics, Inc., Cisco Systems, November 1994.
  436.  
  437.    [4] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721,
  438.        Xylogics, Inc., November 1994.
  439.  
  440.    [5] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC
  441.        1722, Xylogics, Inc., November 1994.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Malkin                                                          [Page 8]
  451.  
  452. RFC 1723                     RIP Version 2                 November 1994
  453.  
  454.  
  455. Author's Address
  456.  
  457.    Gary Scott Malkin
  458.    Xylogics, Inc.
  459.    53 Third Avenue
  460.    Burlington, MA 01803
  461.  
  462.    Phone:  (617) 272-8140
  463.    EMail:  gmalkin@Xylogics.COM
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Malkin                                                          [Page 9]
  507.  
  508.